Header compression for cell relay communications

ABSTRACT

Systems and methodologies are described that facilitate compressing packet headers for cell relay communications. Since cell relays can support a number of evolved packet system (EPS) bearers over a given dedicated radio bearer (DRB), robust header compression (RoHC) can be multiplexed for communications to/from a given cell relay. Thus, an upstream node compressing one or more packet headers can indicate a RoHC context, which can be represented by a RoHC context identifier in a RoHC header. A receiving entity can decompress the headers based on determining the RoHC context. Alternatively, the RoHC context can be associated with an identifier of a related UE bearer such as a tunnel endpoint identifier (TEID), a relay identifier, and/or the like, that is received in a tunneling protocol header to facilitate packet routing.

CLAIM OF PRIORITY UNDER 35 U.S.C. §119

The present Application for Patent claims priority to ProvisionalApplication No. 61/108,287 entitled “CELL RELAY BASE STATION FOR LTE”filed Oct. 24, 2008, and assigned to the assignee hereof and herebyexpressly incorporated by reference herein.

BACKGROUND

1. Field

The following description relates generally to wireless communications,and more particularly to compressing protocol headers in communicatingusing cell relays.

2. Background

Wireless communication systems are widely deployed to provide varioustypes of communication content such as, for example, voice, data, and soon. Typical wireless communication systems may be multiple-accesssystems capable of supporting communication with multiple users bysharing available system resources (e.g., bandwidth, transmit power, . .. ). Examples of such multiple-access systems may include code divisionmultiple access (CDMA) systems, time division multiple access (TDMA)systems, frequency division multiple access (FDMA) systems, orthogonalfrequency division multiple access (OFDMA) systems, and the like.Additionally, the systems can conform to specifications such as thirdgeneration partnership project (3GPP), 3GPP long term evolution (LTE),ultra mobile broadband (UMB), and/or multi-carrier wirelessspecifications such as evolution data optimized (EV-DO), one or morerevisions thereof, etc.

Generally, wireless multiple-access communication systems maysimultaneously support communication for multiple mobile devices. Eachmobile device may communicate with one or more access points (e.g., basestations) via transmissions on forward and reverse links. The forwardlink (or downlink) refers to the communication link from access pointsto mobile devices, and the reverse link (or uplink) refers to thecommunication link from mobile devices to access points. Further,communications between mobile devices and access points may beestablished via single-input single-output (SISO) systems,multiple-input single-output (MISO) systems, multiple-inputmultiple-output (MIMO) systems, and so forth. Access points, however,can be limited in geographic coverage area as well as resources suchthat mobile devices near edges of coverage and/or devices in areas ofhigh traffic can experience degraded quality of communications from anaccess point.

Cell relays can be provided to expand network capacity and coverage areaby facilitating communication between mobile devices and access points.For example, a cell relay can establish a backhaul link with a donoraccess point, which can provide access to a number of cell relays, andthe cell relay can establish an access link with one or more mobiledevices or additional cell relays. To mitigate modification to backendcore network components, communication interfaces, such as S1-U, canterminate at the donor access point. Thus, the donor access pointappears as a normal access point to backend network components. To thisend, the donor access point can route packets from the backend networkcomponents to the cell relays for communicating to the mobile devices.

SUMMARY

The following presents a simplified summary of one or more aspects inorder to provide a basic understanding of such aspects. This summary isnot an extensive overview of all contemplated aspects, and is intendedto neither identify key or critical elements of all aspects nordelineate the scope of any or all aspects. Its sole purpose is topresent some concepts of one or more aspects in a simplified form as aprelude to the more detailed description that is presented later.

In accordance with one or more aspects and corresponding disclosurethereof, various aspects are described in connection with facilitatingcompressing protocol headers to provide efficient communication amongcell relays. In particular, robust header compression (RoHC) contextsfor multiple evolved packet system (EPS) bearers can be supported over asingle dedicated radio bearer of a cell relay. In one example, a singlerobust header compressor can be provided at one communication node and asingle robust header decompressor at the other in relay communications.In this example, the multiple RoHC contexts for the given EPS bearerscan be differentiated according to assigned context identifiers. Inanother example, multiple robust header compressors/decompressors can beprovided at the communication nodes for each RoHC context, and a tunnelendpoint identifier (TEID) or similar identifier related to the EPSbearers (or corresponding UE bearers) can be utilized to differentiateEPS bearers at the nodes. In addition, to facilitate header compressionwithin the RoHC contexts, a donor eNB can compress a tunneling protocolheader in a packet received from an upstream network node for downstreamcommunication of the packet.

According to related aspects, a method is provided that includesreceiving a packet with a RoHC compressed header from at least one of aplurality of EPS bearers mapped to a dedicated radio bearer (DRB). Themethod also includes determining a RoHC context for the RoHC compressedheader and decompressing the RoHC compressed header based at least inpart on the RoHC context.

Another aspect relates to a wireless communications apparatus. Thewireless communications apparatus can include at least one processorconfigured to obtain a packet with a RoHC compressed header from one ofa plurality of EPS bearers mapped to a DRB of the wirelesscommunications apparatus and discern a RoHC context used for compressionof the RoHC compressed header. The at least one processor is furtherconfigured to discern a RoHC context used for compression of the RoHCcompressed header. The wireless communications apparatus also comprisesa memory coupled to the at least one processor.

Yet another aspect relates to an apparatus. The apparatus includes meansfor receiving a packet with a RoHC compressed header from at least oneof a plurality of EPS bearers mapped to a DRB and means for determininga RoHC context for the RoHC compressed header. The apparatus alsoincludes means for decompressing the RoHC compressed header based atleast in part on the RoHC context.

Still another aspect relates to a computer program product, which canhave a computer-readable medium including code for causing at least onecomputer to receive a packet with a RoHC compressed header from at leastone of a plurality of EPS bearers mapped to a DRB and code for causingthe at least one computer to determine a RoHC context for the RoHCcompressed header. The computer-readable medium can also comprise codefor causing the at least one computer to decompress the RoHC compressedheader based at least in part on the RoHC context.

Moreover, an additional aspect relates to an apparatus including abearer communicating component that receives a packet with a RoHCcompressed header from at least one of a plurality of EPS bearers mappedto a DRB. The apparatus can further include a RoHC context determiningcomponent that discerns a RoHC context for the RoHC compressed headerand a RoHC decompressing component that decompresses the RoHC compressedheader based at least in part on the RoHC context.

In another aspect, a method is provided that includes compressing aheader of a packet received over an EPS bearer using RoHC based at leastin part on a RoHC context and indicating an identifier related to theRoHC context in the packet. The method further includes transmitting thepacket over a DRB to which the EPS bearer and one or more additional EPSbearers are mapped.

Another aspect relates to a wireless communications apparatus. Thewireless communications apparatus can include at least one processorconfigured to compress a header of a packet received over an EPS bearerbased at least in part on a selected RoHC context and specify anidentifier related to the selected RoHC context in the packet. The atleast one processor is further configured to communicate the packet overa DRB to which the EPS bearer and one or more disparate EPS bearers in acore network are mapped. The wireless communications apparatus alsocomprises a memory coupled to the at least one processor.

Yet another aspect relates to an apparatus. The apparatus includes meansfor compressing a header of a packet received over an EPS bearer basedat least in part on a RoHC context and means for indicating anidentifier related to the RoHC context in the packet. The apparatus alsoincludes means for transmitting the header over a DRB to which the EPSbearer and one or more additional EPS bearers are mapped.

Still another aspect relates to a computer program product, which canhave a computer-readable medium including code for causing at least onecomputer to compress a header of a packet received over an EPS bearerusing RoHC based at least in part on a RoHC context and code for causingthe at least one computer to indicate an identifier related to the RoHCcontext in the packet. The computer-readable medium can also comprisecode for causing the at least one computer to transmit the packet over aDRB to which the EPS bearer and one or more additional EPS bearers aremapped.

Moreover, an additional aspect relates to an apparatus including a RoHCcompressing component that compresses a header of a packet received overan EPS bearer using RoHC based at least in part on a RoHC context. Theapparatus can further include a context identifying component thatspecifies an identifier related to the RoHC context in the packet and abearer communicating component that transmits the header over a DRB towhich the EPS bearer and one or more additional EPS bearers are mapped.

According to yet another aspect, a method is provided that includesreceiving a packet from an upstream node comprising a user datagramprotocol (UDP), internet protocol (IP), or general packet radio service(GPRS) tunneling protocol (GTP) header. The method further includescompressing a header of the packet to include a compressed SGW IPaddress and transmitting the packet with the compressed header to adownstream node.

Another aspect relates to a wireless communications apparatus. Thewireless communications apparatus can include at least one processorconfigured to obtain a packet from an upstream node comprising a UDP,IP, or GTP header and associate a compressed header with the packet thatincludes a compressed SGW IP address. The at least one processor isfurther configured to transmit the packet with the compressed header toa downstream node. The wireless communications apparatus also comprisesa memory coupled to the at least one processor.

Yet another aspect relates to an apparatus. The apparatus includes meansfor receiving a packet from an upstream node comprising a UDP, IP, orGTP header and means for applying compression to a header of the packetto compress at least an SGW IP address. The apparatus also includesmeans for transmitting the packet with the compressed header to adownstream node.

Still another aspect relates to a computer program product, which canhave a computer-readable medium including code for causing at least onecomputer to receive a packet from an upstream node comprising a UDP, IP,or GTP header. The computer-readable medium can also comprise code forcausing the at least one computer to compress a header of the packet toinclude a compressed SGW IP address and code for causing the at leastone computer to transmit the packet with the compressed header to adownstream node.

Moreover, an additional aspect relates to an apparatus including an IPpacket receiving component that receives a packet from an upstream nodecomprising a UDP, IP, or GTP header and a header compressing componentcompresses a header of the packet at least in part by compressing an SGWIP address in the header. The apparatus can further include a bearercommunicating component that transmits the packet with the compressedheader to a downstream node.

To the accomplishment of the foregoing and related ends, the one or moreaspects comprise the features hereinafter fully described andparticularly pointed out in the claims. The following description andthe annexed drawings set forth in detail certain illustrative featuresof the one or more aspects. These features are indicative, however, ofbut a few of the various ways in which the principles of various aspectsmay be employed and this description is intended to include all suchaspects and their equivalents.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an illustration of an example wireless communications systemthat facilitates providing relays for wireless networks.

FIG. 2 is an illustration of an example wireless communications systemthat facilitates compressing headers for cell relay communication usingrobust header compression (RoHC).

FIG. 3 is an illustration of an example wireless communications systemthat communicates packets with RoHC compressed header for multiple EPSbearers over a single dedicated radio bearer (DRB).

FIG. 4 is an illustration of an example wireless communications systemthat facilitates compressing headers using a RoHC context thatcorresponds to a downstream bearer identifier.

FIG. 5 is an illustration of an example wireless communications systemthat communicates packets with RoHC headers compressed according to aRoHC context that corresponds to a downstream bearer identifier.

FIG. 6 is an illustration of an example wireless communications systemthat encapsulates RoHC compressed packets for subsequent routing.

FIG. 7 is an illustration of an example wireless communications systemthat utilizes cell relays to provide access to a wireless network.

FIG. 8 is an illustration of example protocol stacks that facilitateproviding cell relay functionality for data plane communications.

FIG. 9 is an illustration of example protocol stacks that facilitateproviding cell relay functionality for data plane communications using arelay protocol.

FIG. 10 is an illustration of an example methodology for decompressing aRoHC compressed header based on a determined RoHC context.

FIG. 11 is an illustration of an example methodology that compresses oneor more packet headers using a RoHC context.

FIG. 12 is an illustration of an example methodology that encapsulates apacket for subsequent routing.

FIG. 13 is an illustration of an example methodology that determines anencapsulation for a received packet.

FIG. 14 is an illustration of an example methodology that compresses auser datagram protocol (UDP), internet protocol (IP), or general packetradio service (GPRS) tunneling protocol (GTP) header of a receivedpacket.

FIG. 15 is an illustration of a wireless communication system inaccordance with various aspects set forth herein.

FIG. 16 is an illustration of an example wireless network environmentthat can be employed in conjunction with the various systems and methodsdescribed herein.

FIG. 17 is an illustration of an example system that facilitatesdecompressing a RoHC compressed header based on a determined RoHCcontext.

FIG. 18 is an illustration of an example system that facilitatescompressing a header according to a RoHC context.

FIG. 19 is an illustration of an example system that facilitatescompressing a UDP, IP, or GTP header.

DETAILED DESCRIPTION

Various aspects are now described with reference to the drawings. In thefollowing description, for purposes of explanation, numerous specificdetails are set forth in order to provide a thorough understanding ofone or more aspects. It may be evident, however, that such aspect(s) maybe practiced without these specific details.

As used in this application, the terms “component,” “module,” “system”and the like are intended to include a computer-related entity, such asbut not limited to hardware, firmware, a combination of hardware andsoftware, software, or software in execution. For example, a componentmay be, but is not limited to being, a process running on a processor, aprocessor, an object, an executable, a thread of execution, a program,and/or a computer. By way of illustration, both an application runningon a computing device and the computing device can be a component. Oneor more components can reside within a process and/or thread ofexecution and a component may be localized on one computer and/ordistributed between two or more computers. In addition, these componentscan execute from various computer readable media having various datastructures stored thereon. The components may communicate by way oflocal and/or remote processes such as in accordance with a signal havingone or more data packets, such as data from one component interactingwith another component in a local system, distributed system, and/oracross a network such as the Internet with other systems by way of thesignal.

Furthermore, various aspects are described herein in connection with aterminal, which can be a wired terminal or a wireless terminal Aterminal can also be called a system, device, subscriber unit,subscriber station, mobile station, mobile, mobile device, remotestation, remote terminal, access terminal, user terminal, terminal,communication device, user agent, user device, or user equipment (UE). Awireless terminal may be a cellular telephone, a satellite phone, acordless telephone, a Session Initiation Protocol (SIP) phone, awireless local loop (WLL) station, a personal digital assistant (PDA), ahandheld device having wireless connection capability, a computingdevice, or other processing devices connected to a wireless modem.Moreover, various aspects are described herein in connection with a basestation. A base station may be utilized for communicating with wirelessterminal(s) and may also be referred to as an access point, a Node B,evolved Node B (eNB), or some other terminology.

Moreover, the term “or” is intended to mean an inclusive “or” ratherthan an exclusive “or.” That is, unless specified otherwise, or clearfrom the context, the phrase “X employs A or B” is intended to mean anyof the natural inclusive permutations. That is, the phrase “X employs Aor B” is satisfied by any of the following instances: X employs A; Xemploys B; or X employs both A and B. In addition, the articles “a” and“an” as used in this application and the appended claims shouldgenerally be construed to mean “one or more” unless specified otherwiseor clear from the context to be directed to a singular form.

The techniques described herein may be used for various wirelesscommunication systems such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA and othersystems. The terms “system” and “network” are often usedinterchangeably. A CDMA system may implement a radio technology such asUniversal Terrestrial Radio Access (UTRA), cdma2000, etc. UTRA includesWideband-CDMA (W-CDMA) and other variants of CDMA. Further, cdma2000covers IS-2000, IS-95 and IS-856 standards. A TDMA system may implementa radio technology such as Global System for Mobile Communications(GSM). An OFDMA system may implement a radio technology such as EvolvedUTRA (E-UTRA), Ultra Mobile Broadband (UMB), IEEE 802.11 (Wi-Fi), IEEE802.16 (WiMAX), IEEE 802.20, Flash-OFDM, etc. UTRA and E-UTRA are partof Universal Mobile Telecommunication System (UMTS). 3GPP Long TermEvolution (LTE) is a release of UMTS that uses E-UTRA, which employsOFDMA on the downlink and SC-FDMA on the uplink. UTRA, E-UTRA, UMTS, LTEand GSM are described in documents from an organization named “3rdGeneration Partnership Project” (3GPP). Additionally, cdma2000 and UMBare described in documents from an organization named “3rd GenerationPartnership Project 2” (3GPP2). Further, such wireless communicationsystems may additionally include peer-to-peer (e.g., mobile-to-mobile)ad hoc network systems often using unpaired unlicensed spectrums, 802.xxwireless LAN, BLUETOOTH and any other short- or long-range, wirelesscommunication techniques.

Various aspects or features will be presented in terms of systems thatmay include a number of devices, components, modules, and the like. Itis to be understood and appreciated that the various systems may includeadditional devices, components, modules, etc. and/or may not include allof the devices, components, modules etc. discussed in connection withthe figures. A combination of these approaches may also be used.

Referring to FIG. 1, a wireless communication system 100 is illustratedthat facilitates providing relay functionality in wireless networks.System 100 includes a donor eNB 102 that provides one or more relayeNBs, such as relay eNB 104, with access to a core network 106.Similarly, relay eNB 104 can provide one or more disparate relay eNBs,such as relay eNB 108, or UEs, such as UE 110, with access to the corenetwork 106 via donor eNB 102. Donor eNB 102, which can also be referredto as a cluster eNB, can communicate with the core network 106 over awired or wireless backhaul link, which can be an LTE or other technologybackhaul link. In one example, the core network 106 can be a 3GPP LTE orsimilar technology network.

Donor eNB 102 can additionally provide an access link for relay eNB 104,which can also be wired or wireless, LTE or other technologies, and therelay eNB 104 can communicate with the donor eNB 102 using a backhaullink over the access link of the donor eNB 102. Relay eNB 104 cansimilarly provide an access link for relay eNB 108 and/or UE 110, whichcan be a wired or wireless LTE or other technology link. In one example,donor eNB 102 can provide an LTE access link, to which relay eNB 104 canconnect using an LTE backhaul, and relay eNB 104 can provide an LTEaccess link to relay eNB 108 and/or UE 110. Donor eNB 102 can connect tothe core network 106 over a disparate backhaul link technology. RelayeNB 108 and/or UE 110 can connect to the relay eNB 104 using the LTEaccess link to receive access to core network 106, as described. A donoreNB and connected relay eNBs can be collectively referred to herein as acluster.

According to an example, relay eNB 104 can connect to a donor eNB 102 atthe link layer (e.g., media access control (MAC) layer) as would a UE inregular LTE configurations. In this regard, donor eNB 102 can be aregular LTE eNB requiring no changes at the link layer or relatedinterface (e.g., E-UTRA-Uu) to support the relay eNB 104. In addition,relay eNB 104 can appear to UE 110 as a regular eNB at the link layer,such that no changes are required for UE 110 to connect to relay eNB 104at the link layer, for example. In addition, relay eNB 104 can configureprocedures for resource partitioning between access and backhaul link,interference management, idle mode cell selection for a cluster, and/orthe like.

With respect to transport layer communications, transport protocolsrelated to relay eNB 108 or UE 110 communications can terminate at thedonor eNB 102, referred to as cell relay functionality, since the relayeNB 104 is like a cell of the donor eNB 102. For example, in a cellrelay configuration, donor eNB 102 can receive communications for therelay eNB 104 from the core network 106, terminate the transportprotocol, and forward the communications to the relay eNB 104 over adisparate transport layer keeping the application layer substantiallyintact. It is to be appreciated that the forwarding transport protocoltype can be the same as the terminated transport protocol type, but is adifferent transport layer established with the relay eNB 104.

Relay eNB 104 can determine a relay eNB or UE related to thecommunications, and provide the communications to the relay eNB or UE(e.g., based on an identifier thereof within the communications).Similarly, donor eNB 102 can terminate the transport layer protocol forcommunications received from relay eNB 104, translate the communicationsto a disparate transport protocol, and transmit the communications overthe disparate transport protocol to the core network 106 with theapplication layer intact for relay eNB 104 as a cell relay. In theseexamples, where relay eNB 104 is communicating with another relay eNB,the relay eNB 104 can support application protocol routing to ensurecommunications reach the correct relay eNB.

Moreover, application layer protocols can terminate at upstream eNBs.Thus, for example, application layer protocols for relay eNB 108 and UE110 can terminate at relay eNB 104, and similarly for relay eNB 104 canterminate at donor eNB 102. The transport and application layerprotocols, for example, can relate to S1-U, S1-MME, and/or X2interfaces. S1-U interface can be utilized to communicate in a dataplane between a node and a serving gateway (not shown) of the corenetwork 106. S1-MME interface can be utilized for control planecommunications between a node and a mobility management entity (MME)(not shown) of the core network 106. X2 interface can be utilized forcommunications between eNBs. In addition, for example, donor eNB 102 cancommunicate with other relay eNBs to allow communications therebetweenover the access network (e.g., relay eNB 104 can communicate with one ormore additional relay eNBs connected to donor eNB 102).

According to an example, relay eNB 104 (and relay eNB 108) can mapmultiple evolved packet system (EPS) bearers at core network 106 to asingle dedicated radio bearer (DRB) to support a plurality of downstreamUEs, such as UE 110, and/or bearers related thereto. In addition, relayeNB 104 can support robust header compression (RoHC) for the multiple UEbearers. In one example, donor eNB 102 can have a single RoHC compressorand/or decompressor instance for a DRB of relay eNB 104, and relay eNB104 can similarly have a single decompressor and/or compressor for agiven dedicated radio bearer. In this example, donor eNB 102 cancompress packet headers (e.g., internet protocol (IP), user datagramprotocol (UDP) and/or similar packet headers) for multiple EPS bearersover a single DRB. For example, donor eNB 102 can insert a RoHC contextidentifier in the RoHC header, and the relay eNB 104 can differentiatethe RoHC contexts based on the RoHC context identifiers. In this regard,relay eNB 104 can apply appropriate decompression to the headers.Similarly, relay eNB 104 can compress and donor eNB 102 can decompressusing the RoHC context identifiers. It is to be appreciated that a RoHCcontext can refer to a procedure utilized to compress one or more packetheaders for efficient transmission thereof and can differ according to atype of bearer and/or data transmitted thereover, a destination node ortype thereof, available resources, and/or the like.

In another example, donor eNB 102 can have one or more RoHC compressorsand/or decompressors for each EPS bearer mapped to the DRB of relay eNB104. Similarly, relay eNB 104 can have one or more RoHC decompressorsand/or compressors for each EPS bearer. In this example, a RoHCcompressor of the donor eNB 102 can compress the packet headers, anddonor eNB 102 can encapsulate the compressed IP header and the IP packetfor a given EPS bearer in a tunneling protocol header that includes atunnel endpoint identifier (TEID) related to the EPS bearer (and/or acorresponding UE 110 bearer). In one example, the tunneling protocol canbe general packet radio service (GPRS) tunneling protocol (GTP)-U. Inanother example, donor eNB 102 can encapsulate the IP packet (or theGTP-U packet) in a relay protocol (RP) header that facilitates packetrouting based on a relay identifier comprised in the RP packet header.

Upon receiving the encapsulated packet, relay eNB 104 can extract the IPheader and packet, for example, and one of the decompressors of relayeNB 104 can determine the RoHC context based at least in part on theTEID. In another example, one of the decompressors can determine theRoHC based additionally or alternatively on the relay identifier. Inthis regard, the decompressor can apply the appropriate decompression tothe header. Similarly, relay eNB 104 can compress and donor eNB 102 candecompress using TEID to determine RoHC context, as described.

In addition, it is to be appreciated that similarcompression/decompression can be performed in relay eNB 104 to relay eNB108 communications (e.g., as related to a bearer of a UE communicatingwith relay eNB 108). Moreover, a header for the tunneling protocol canalso be compressed. In one example, the header can include an address ofan upstream network node, such as a serving gateway (SGW) that can becompressed. The tunneling protocol can be transmitted over a packet dataconvergence protocol (PDCP) layer with an associated IP packet. Thus,for example, PDCP configuration can be extended to include a payloadtype that specifies whether the packet has an IP, GTP-U, or RP header.

Turning now to FIG. 2, an example wireless communication system 200 thatfacilitates RoHC for multiple EPS bearers mapped to a given cell relaybearer is illustrated. System 200 includes a donor eNB 102 that providesrelay eNB 104 (and/or other relay eNBs) with access to core network 106.Additionally, as described, relay eNB 104 can provide one or moredevices, such as UE 110, and/or other relay eNBs with access to the corenetwork 106 through the donor eNB 102. In addition, it is to beappreciated that relay eNB 104 can comprise the components of donor eNB102, and vice versa, to provide similar functionality, in one example.Moreover, donor eNB 102 can be a macrocell access point, femtocellaccess point, picocell access point, mobile base station, and/or thelike. Relay eNB 104 can similarly be mobile or stationary relay nodesthat communicate with donor eNB 102 over a wireless or wired backhaul,as described.

Donor eNB 102 comprises a RoHC context selecting component 202 thatdetermines a RoHC context or related identifier for packets receivedover an EPS bearer, a RoHC compressing component 204 that appliescompression to packet headers received over the EPS bearer based atleast in part on the RoHC context, a RoHC context indicating component206 that specifies the selected RoHC context in a RoHC header of thecompressed communication, and a bearer communicating component 208 thattransmits communications to and/or receives communications from a DRB ofa relay eNB. Relay eNB 104 can include a bearer communicating component210 that receives communications from and/or transmits communications toa core network 106 over an EPS bearer (e.g., through one or moreupstream nodes), a RoHC context determining component 212 that obtains aRoHC context of packet headers received over a DRB mapped to one or moreEPS bearers based at least in part on an identifier in the RoHC headersof the packets, and a RoHC decompressing component 214 that appliesdecompression to the packet headers based at least in part on thedetermined RoHC context.

According to an example, donor eNB 102 can receive communications forrelay eNB 104 (and/or one or more relay eNBs or devices, such as UE 110,communicating directly or indirectly therewith). For example, corenetwork 106 can have previously established an EPS bearer that maps to abearer of UE 110. Relay eNB 104, as an intermediary node, can haveestablished a bearer to which core network 106 that actually maps theEPS bearer and can forward data transmitted over the EPS bearer to UE110. As described, relay eNB 104 can support multiple directly connectedUEs as well as relay eNBs, which can have connected UEs or additionalrelay eNBs, etc. Thus, relay eNB 104 can be required to support a numberof EPS bearers given a limited number of DRBs at relay eNB 104. Thus,RoHC can be performed to support a number of EPS bearers over a singleDRB.

In an example, once communications are received from core network 106,RoHC context selecting component 202 can determine a RoHC context forthe communications. In one example, this can be based at least in parton a type of the EPS bearer or related communications (e.g., voice,video, gaming, etc.), the relay eNB receiving the data (e.g., relay eNB104 in this example), available system resources, and/or the like. RoHCcompressing component 204 can apply a RoHC compression to thecommunications, or headers thereof, to facilitate efficient transmissionof the communications over a DRB. In one example, the RoHC compressingcomponent 204 can compress a header of an IP packet by removing orreplacing one or more parameters in the IP packet header previouslycommunicated to relay eNB 104.

This can include providing a RoHC header for the communications. Inaddition, the RoHC context can have an associated identifier, forexample, that can be utilized to indicate and subsequently determine theRoHC context type. In this regard, RoHC context indicating component 206can insert the identifier in the header. Bearer communicating component208 can provide the RoHC compressed communication to relay eNB 104 overa mapped DRB. As described, for example, bearer communicating component208 can simultaneously provide additional RoHC compressed communicationsfor disparate EPS bearers over the DRB. In one example, bearercommunicating component 208 can provide the RoHC compressedcommunication to relay eNB 104 based at least in part on locating anassociation between an identifier of a tunneling protocol header of thecommunication and relay eNB 104 in a routing table.

Bearer communicating component 210 can receive the RoHC compressedcommunications. RoHC context determining component 212 can evaluate anidentifier in the RoHC header to determine the RoHC context. RoHCdecompressing component 214 can decompress the communications, orrelated headers, based on the determined RoHC context, for example. Itis to be appreciated, for example, that the RoHC context identifiers canbe known by the donor eNB 102 and/or relay eNB 104 according to aspecification, configuration, previous communications, and/or the like.Additionally, using a RoHC context identifier mitigates the need totransmit other RoHC context information required for decompressing theRoHC packet, which decreases bandwidth requirements. Indeed, the contextidentifier can be specified as a small number of bits in the RoHCheader. The RoHC context header, in one example, can relate not only tothe type of communications and/or the related RoHC compression applied,but can also be specific to a corresponding destination node (e.g., UE110, or another relay eNB or UE communicating directly or indirectlywith relay eNB 104).

Moreover, as described, the RoHC functionality for multiple EPS bearersmapped to a single DRB can be provided for relay eNB 104 communicatingwith a downstream relay eNB. Indeed, substantially any two communicatingnodes can utilize the components described herein having a RoHCcompressing component 204 at one node and a RoHC decompressing component214 at the other. The example shown with donor eNB 102 communicatingwith relay eNB 104 is but one possible implementation.

Referring to FIG. 3, an example wireless communication system 300 formultiplexing multiple RoHC compressed EPS bearers over a single DRB isillustrated. System 300 includes a donor eNB 102 that provides wirelessnetwork access to relay eNB 104, as described. Donor eNB 102 can includea RoHC compressing/decompressing component 302 that provides a singleinstance of a RoHC compressor and decompressor for communicatingmultiple EPS bearer RoHC packets over a single DRB 306 to relay eNB 104.Similarly, relay eNB 104 can include a RoHC compressing/decompressingcomponent 304 that provides a single instance of a RoHC compressor anddecompressor for communicating multiple EPS bearer RoHC packets over asingle DRB 306 to donor eNB 102. For example, as shown, RoHCcompressing/decompressing component 302 can compress communications forEPS bearer 1 (e.g., received from a core network (not shown)) accordingto a RoHC context corresponding to identifier 0, and can transmit thecommunication over DRB 306 as represented at 308. RoHCcompressing/decompressing component 304 can decompress communicationsreceived from EPS bearer 1 according to the RoHC context represented byidentifier 0.

Similarly, as described, RoHC compressing/decompressing component 304can compress communications to be transmitted over EPS bearer 1according to RoHC context with identifier 0 and transmit the compressedcommunications to donor eNB 102. RoHC compressing/decompressingcomponent 302 can decompress the communications according to the RoHCcontext represented by identifier 0, as described, for forwarding datacomprised in the RoHC communication to a core network. As described, theRoHC contexts and associated identifiers can be known at donor eNB 102and/or relay eNB 104, such as according to a configuration,specification, and/or the like.

Similarly, RoHC compressing/decompressing component 302 cancompress/decompress communications over EPS bearer 2 using RoHC contextwith identifier 1 at 310, communications over EPS bearer 3 using RoHCcontext with identifier 2 at 310, communications over EPS bearer 4 usingRoHC context with identifier 3 at 310, and communications over EPSbearer 5 using RoHC context with identifier 4 at 310 over DRB 306. Inone example, RoHC context identifier 0 can be represented in the RoHCheader as zero bytes. RoHC context identifiers, for example, can rangefrom 0-15, where 1-15 can be represented as a 4-bit field in the RoHCheader. Moreover, for example, the RoHC context identifiers can beextended to a larger number to balance a number of supported contextswith a desired bandwidth utilization.

Referring to FIG. 4, an example wireless communication system 400 forcommunicating RoHC compressed headers for multiple EPS bearers over asingle DRB is illustrated. System 400 includes a donor eNB 102 thatprovides relay eNB 104 (and/or other relay eNBs) with access to corenetwork 106. Additionally, as described, relay eNB 104 can provide oneor more devices, such as UE 110, and/or other relay eNBs with access tothe core network 106 through the donor eNB 102. In addition, it is to beappreciated that relay eNB 104 can comprise the components of donor eNB102, and vice versa, to provide similar functionality, in one example.Moreover, donor eNB 102 can be a macrocell access point, femtocellaccess point, picocell access point, mobile base station, and/or thelike. Relay eNB 104 can similarly be mobile or stationary relay nodesthat communicate with donor eNB 102 over a wireless or wired backhaul,as described.

Donor eNB 102 comprises a RoHC compression instance component 402 thatinitializes a RoHC compressor for compressing headers of one or morepackets received from core network 106, a packet encapsulating component404 that creates a tunneling protocol header for routing compressedheader packets, an identifier specifying component 406 that inserts aTEID or other relay identifier related to the relay eNB 104 in thetunneling protocol header to facilitate routing the packet, and a bearercommunicating component 208 that transmits communications to and/orreceives communications from a DRB of a relay eNB. Relay eNB 104 caninclude a bearer communicating component 210 that receivescommunications from and/or transmits communications to a core network106 over an EPS bearer (e.g., through one or more upstream nodes), anidentifier receiving component 408 that determines an identifier in areceived tunneling protocol header, a RoHC context determining component212 that discerns a RoHC context based at least in part on theidentifier, and a RoHC decompression instance component 410 thatinitializes a RoHC decompressor that can decompress packet headers basedat least in part on the received identifier.

According to an example, donor eNB 102 can receive communications forrelay eNB 104 (and/or one or more relay eNBs or devices, such as UE 110,communicating directly or indirectly therewith). For example, corenetwork 106 can have previously established an EPS bearer that maps to abearer of UE 110. Relay eNB 104, as an intermediary node, can haveestablished a bearer to which core network 106 (e.g., that actually mapsthe EPS bearer) and can forward data transmitted over the EPS bearer toUE 110. As described, relay eNB 104 can support multiple directlyconnected UEs as well as relay eNBs, which can also have connected UEsor additional relay eNBs, etc. Thus, relay eNB 104 can be required tosupport a number of EPS bearers given a limited number of DRBs at relayeNB 104. Thus, RoHC can be performed to support a number of EPS bearersover a single DRB.

In an example, once IP packets (or other packets) are received from corenetwork 106, RoHC compression instance component 402 can create a RoHCcompressor for the packet (and/or other packets received over the sameEPS bearer, for example), which can compress the IP packet headeraccording to one or more RoHC compression specifications. Packetencapsulating component 404 can create a tunneling protocol header forthe RoHC packets. In one example, the tunneling protocol header can be aGTP-U header, an RP header, and/or the like, and can be compressed aswell. In one example, packet encapsulating component 404 can encapsulatethe IP header and packet in a GTP-U header, for example. Identifierspecifying component 406 can include an identifier, such as a TEID orportion thereof, in the GTP-U header. Moreover, in another example,packet encapsulating component 404 can additionally encapsulate theentire packet along with the GTP-U header in a relay protocol packet.Identifier specifying component 406 can include a relay identifier inthe relay protocol packet header.

Bearer communicating component 208 can provide the encapsulatedcommunication to relay eNB 104 over a mapped DRB. As described, forexample, bearer communicating component 208 can simultaneously provideadditional RoHC compressed communications for disparate EPS bearers overthe DRB. In one example, bearer communicating component 208 can providethe encapsulated communication to relay eNB 104 based at least in parton locating an association between an identifier in a header of thecommunication (e.g., a TEID and/or relay identifier) and relay eNB 104in a routing table.

Bearer communicating component 210 can receive the encapsulatedcommunication. Identifier receiving component 408 can determine anidentifier in the tunneling protocol header (e.g., TEID and/or relayidentifier, as described). RoHC context determining component 212 candetermine a RoHC context utilized to compress the headers based at leastin part on the identifier. RoHC decompression instance component 410 caninitialize a RoHC decompressor that decompresses the IP packet header,which can be extracted from the relay protocol payload in one example,according to the RoHC context. In this regard, additional RoHC contextparameters need not be transmitted among the donor eNB 102 and relay eNB104; rather, relay eNB 104 can RoHC decompress the IP packet headerbased on the TEID or relay identifier of relay eNB 104. In addition, forexample, a type of RoHC compression for the EPS bearer can be previouslycommunicated between donor eNB 102 and relay eNB 104 and each node canstore an association between the type of RoHC compression and theidentifier of relay eNB 104. In another example, an EPS bearer type canbe known at donor eNB 102 and relay eNB 104, and the RoHC context can bebased on the EPS bearer type. It is to be appreciated that the RoHCdecompressor can similarly be utilized to decompress headers ofadditional IP packets received over the corresponding EPS bearer.

Moreover, as described, the RoHC functionality based on an identifier ofrelay eNB 104 for multiple EPS bearers mapped to a single DRB can beprovided for relay eNB 104 communicating with a downstream relay eNB.Indeed, substantially any two communicating nodes can utilize thecomponents described herein having a plurality of RoHC compressors atone node and a plurality of corresponding RoHC decompressors at theother. In addition, relay eNB 104 can perform the compressing and donoreNB 102 the decompressing, in another example. The example shown withdonor eNB 102 communicating with relay eNB 104 is but one possibleimplementation.

Referring to FIG. 5, an example wireless communication system 500 formultiplexing multiple RoHC compressed EPS bearers over a single DRBbased on an identifier of relay eNB 104 is illustrated. System 500includes a donor eNB 102 that provides wireless network access to relayeNB 104, as described. Donor eNB 102 can include a RoHCcompressing/decompressing component 502 that provides multiple RoHCcompressing instances 506, 508, 510, and 512 for compressingcommunications over a provided DRB 306. Similarly, relay eNB 104 caninclude a RoHC compressing/decompressing component 504 that providesmultiple RoHC decompressing instances 514, 516, 518, and 520 fordecompressing communications over DRB 306.

For example, as shown, RoHC compressing instance 506 can compresscommunications and/or related headers received over EPS bearer 1 using aRoHC context related to relay identifier AABB at 522. For example, theidentifier can be an identifier assigned to relay eNB 104 and/or arelated downstream bearer by donor eNB 102, such as a TEID and/or relayidentifier. In another example, the identifier can be a concatenation ofa portion assigned by donor eNB 102 to the relay eNB 104 or downstreambearer and a portion assigned by another node (e.g., relay eNB 104 forthe downstream bearer). In any case, the identifier can be unique suchthat RoHC decompressing instance 514 can determine and apply a RoHCdecompression context to compress communications according to theidentifier.

Similarly, RoHC compressing instance 508 can compress communicationsover EPS bearer 2 according to identifier CCDD at 524, and RoHCdecompressing instance 516 can decompress the compressed communicationsor related headers based on the identifier. In addition, as shown, RoHCcompressing instance 510 can compress communications over EPS bearer 3according to identifier EEFF at 526, and RoHC decompressing instance 518can decompress the compressed communications or related headers based onthe identifier. Moreover, RoHC compressing instance 512 can compresscommunications over EPS bearer 4 according to identifier GGHH at 528,and RoHC decompressing instance 520 can decompress the compressedcommunications or related headers based on the identifier.

Referring to FIG. 6, an example wireless communication system 600 forcompressing packet headers is illustrated. System 600 includes a donoreNB 102 that provides relay eNB 104 (and/or other relay eNBs) withaccess to core network 106. Additionally, as described, relay eNB 104can provide one or more devices, such as UE 110, and/or other relay eNBswith access to the core network 106 through the donor eNB 102. Inaddition, it is to be appreciated that relay eNB 104 can comprise thecomponents of donor eNB 102, and vice versa, to provide similarfunctionality, in one example. Moreover, donor eNB 102 can be amacrocell access point, femtocell access point, picocell access point,mobile base station, and/or the like. Relay eNB 104 can similarly bemobile or stationary relay nodes that communicate with donor eNB 102over a wireless or wired backhaul, as described.

Donor eNB 102 comprises an IP packet receiving component 602 thatobtains one or more IP packets from core network 106 for a downstreamnode, a tunneling protocol encapsulating component 604 that associatesthe IP packet and/or header with a tunneling protocol header for packetrouting, a header compressing component 606 that compresses one or moreheaders of the packet, and a bearer communicating component 208 thattransmits communications to and/or receives communications from a DRB ofa relay eNB. Relay eNB 104 can include a bearer communicating component210 that receives communications from and/or transmits communications toa core network 106 over an EPS bearer (e.g., through one or moreupstream nodes), a header decompressing component 608 that decompressesone or more packet headers, and an IP packet retrieving component 610that determines an IP packet for providing to UE 110.

According to an example, IP packet receiving component 602 can obtain anIP packet from core network 106 for providing to UE 110. In this regard,the IP packet can be received with a GTP-U header that includes anidentifier related to UE 110. For example, at least a portion of theidentifier can have been assigned by donor eNB 102 to facilitate routingthe packet through one or more intermediary relay eNBs. As describedpreviously, in one example donor eNB 102 can RoHC compress one or moreheaders of the packet. Tunneling protocol encapsulating component 604can create a tunneling protocol header for the IP packet. For example,the tunneling protocol header, as described, can be a compressed oruncompressed GTP-U header, RP header, and/or the like. In an example,tunneling protocol encapsulating component 604 can include an identifierin the header for subsequent packet routing (e.g., a TEID or relatedportion for a GTP-U header and/or a relay identifier in an RP header).

Header compressing component 606 can apply compression to one or more ofthe headers (e.g., IP header, GTP-U header, UDP header, etc.) to reducea size of the packet. In one example, header compressing component 606can compress a GTP-U header of the received IP packet to a formatsimilar to the following.

Bits Octets 8 7 6 5 4 3 2 1 1 Version PT I E S PN 2 Message Type 3Tunnel Endpoint Identifier (1^(st) Octet) 4 Tunnel Endpoint Identifier(2^(nd) Octet) 5 Tunnel Endpoint Identifier (3^(rd) Octet) 6 TunnelEndpoint Identifier (4^(th) Octet) 7 Sequence Number (1^(st) Octet)¹⁾⁴⁾8 Sequence Number (2^(nd) Octet)¹⁾⁴⁾ 9 N-PDU Number²⁾⁴⁾ 10 NextExtension Header Type³⁾⁴⁾ 11 Compressed SGW IP addresswhere PT is the protocol type, I indicates whether the SGW IP address ispresent in the packet, E is an extension header flag that indicateswhether the next extension header type field has a value, S is asequence number flag that specifies whether the sequence number fieldshave a value, and PN is a flag that indicates whether the N-packet dataunit (N-PDU) field has a value. Thus, for example, the compressed SGW IPaddress can be reduced to one byte. In this regard, donor eNB 102 andrelay eNB 104 can have previously communicated the SGW address andassigned a one byte identifier to save bandwidth by not including thefull address in the compressed GTP-U header (e.g. in a transport addresstranslation response to a transport address translation request receivedfrom relay eNB 104). In another example, header compressing component606 can compress the IP header. In addition, in a PDCP protocol utilizedto carry the compressed GTP-U header or an IP header (e.g., where noencapsulation is applied), header compression component 606 can specifya type of the payload of the compressed packet (e.g., IP, GTP-U, RP,etc.). In this regard, a receiving entity can determine which header iscompressed.

Bearer communicating component 208 can transmit the compressed headerpacket to relay eNB 104. In one example, as described, bearercommunicating component 208 can provide the packet to relay eNB 104based at least in part on locating an association between an identifierof a tunneling protocol header (e.g., TEID, relay protocol, etc., asdescribed) of the communication and relay eNB 104 in a routing table.Bearer communicating component 210 can receive the packet. Headerdecompressing component 608 can determine which header is compressedbased at least in part on a type specified in the PDCP portion of thepacket, as described, and can accordingly decompress the appropriateheader. IP packet retrieving component 610 can obtain the IP packet andcorresponding header once the appropriate header is decompressed. In oneexample, IP packet receiving component 602 can receive a packet with apacket structure similar to the following.

L1/L2 UDP/IP Header GTP Header with TEID IP Packet of Relay eNBwhere L1/L2 represents a layer 1/layer 2 portion of the packet. In thisregard, header compressing component 606 can compress the GTP-U headerand prepare the packet for transmitting to relay eNB 104 over an accesslink, resulting in a packet structure similar to the following, forexample.

L1/L2 RLC PDCP Compressed GTP Header IP PacketThus, for example, header compressing component 606 can additionallyindicate that the packet has a compressed GTP-U header in the PDCPportion of the packet. Upon receiving the packet, as described, headerdecompressing component 608 can interpret the compressed GTP-U header,which can include a destination address for the packet, in one example,and IP packet retrieving component 610 can generate a packet structuresimilar to the following for transmitting to UE 110.

L1/L2 RLC PDCP IP Packet

It is to be appreciated that there can be intermediary relay eNBs (notshown) in the communications path between donor eNB 102 and relay eNB104. In this example, the intermediary relay eNBs can transmit thecompressed GTP-U structure, shown above, without modifying the packetbased at least in part on an identifier (e.g., TEID and/or relayidentifier) in the structure. In addition, it is to be appreciated thatuplink communications from UE 110 to donor eNB 102 can similarly becompressed by relay eNB 104 for transmission. In this example, donor eNB102 can decompress the GTP-U header to create a GTP-U header with anidentifier of a core network 106 component.

Now turning to FIG. 7, an example wireless communication network 700that provides cell relay functionality is depicted. Network 700 includesa UE 110 that communicates with a relay eNB 104, as described, toreceive access to a wireless network. Relay eNB 104 can communicate witha donor eNB 102 using a relay protocol to provide access to a wirelessnetwork, and as described, donor eNB 102 can communicate with an MME 702and/or SGW 704 that relate to the relay eNB 104. SGW 704 can connect toor be coupled with a PGW 706, which provides network access to SGW 704and/or additional SGWs. PGW 706 can communicate with a PCRF 708 toauthenticate/authorize UE 110 to use the network, which can utilize anIMS 710 to provide addressing to the UE 110 and/or relay eNB 104.

According to an example, MME 702 and/or SGW 704 and PGW 706 can berelated to donor eNB 102 serving substantially all relay eNBs in thecluster. Donor eNB 102 can also communicate with an SGW 716 and PGW 718that relate to the UE 110, such that the PGW 718 can assign UE 110 anetwork address to facilitate tunneling communications thereto throughthe relay eNB 104, donor eNB 102, and SGW 716. Moreover, for example,SGW 716 can communicate with an MME 714 to facilitate control planecommunications to and from the UE 110. It is to be appreciated that MME702 and MME 714 can be the same MME, in one example. PGW 718 cansimilarly communicate with a PCRF 708 to authenticate/authorize UE 110,which can communicate with an IMS 710. In addition, PGW 718 cancommunicate directly with the IMS 710 and/or internet 712.

In an example, UE 110 can communicate with the relay eNB 104 over anE-UTRA-Uu interface, as described, and the relay eNB 104 can communicatewith the donor eNB 102 using an E-UTRA-Uu interface or other interfaceusing the relay protocol, as described herein. Donor eNB 102communicates with the MME 702 using an S1-MME interface and the SGW 704and PGW 706 over an S1-U interface, as depicted. In one example, asdescribed, communications received from relay eNB 104 for MME 702 or SGW704/PGW 706 can be over a relay protocol and can have an IP address ofMME 702 or SGW 704/PGW 706 in the relay protocol header. Donor eNB 102can appropriately route the packet according to the IP address and/orpayload type of the relay protocol. In another example, packets fromrelay eNB 104 can comprised a previously assigned TEID or portionthereof. In addition, the transport layers used over the S1-MME and S1-Uinterfaces are terminated at the donor eNB 102, as described. In thisregard, upon receiving communications for the relay eNB 104 from the MME702 or SGW 704, donor eNB 102 can, for example, decouple the applicationlayer from the transport layer by defining a new relay protocol packet,or other protocol layer packet, and transmitting the application layercommunication to the relay eNB 104 in the new protocol packet (over theE-UTRA-Uu interface, in one example). Donor eNB 102 can transmit thepacket to relay eNB 104 (and/or one or more disparate relay eNBs asdescribed) based on a TEID in the packet or relay identifier in theheader.

Upon transmitting control plane communications from the relay eNB 104 tothe MME 702, donor eNB 102 can indicate an identifier of the relay eNB104 (e.g., in an S1-AP message), and MME 702 can transmit the identifierin responding communications to the donor eNB 102. When transmittingdata plane communications from relay eNB 104 to SGW 704, donor eNB 102can insert an identifier for the relay eNB 104 (or UE 110 or one or morerelated bearers) in the TEID of a GTP-U header to identify the relay eNB104 (or UE 110 or one or more related bearers). This can be anidentifier generated for relay eNB 104 by donor eNB 102 such that donoreNB 102 can determine the relay eNB 104, or one or more downstream relayeNBs is to receive the translated packet, as described above. Forexample, this can be based at least in part on locating at least aportion of the identifier in a routing table at donor eNB 102. Inaddition, headers can be compressed, in one example, as described. Asshown, MME 702 can communicate with SGW 704, and MME 714 to SGW 716,using an S7 interface. PGWs 706 and 718 can communicate with PCRF 708over a Gx interface. Furthermore, PCRF 708 can communicate with IMS 710using an Rx interface, and PGW 718 can communicate with IMS 710 and/orthe internet 712 using an SGi interface.

Referring to FIG. 8, example protocol stacks 800 are illustrated thatfacilitate communicating in a wireless network to provide cell relayfunctionality for data (e.g., user) plane communications using a TEIDfor packet routing. A UE protocol stack 802 is shown comprising an L1layer, MAC layer, an RLC layer, a PDCP layer, and an IP layer. A relayeNB (ReNB) access link protocol stack 804 is depicted having an L1layer, MAC layer, RLC layer, and PDCP layer, as well as an ReNB backhaullink protocol stack 806 having an L1 layer, PDCP/RLC/MAC layer, and aC-GTP-U/UDP/IP layer, which can be a compressed layer in one example, tofacilitate routing packets on the backhaul (e.g., by populating the TEIDwith the ReNB address, as described previously). A donor eNB (DeNB)access link protocol stack 808 is also shown having an L1 layer,PDCP/RLC/MAC layer, and a C-GTP/UDP/IP layer, as well as a DeNB backhaullink protocol stack 810 having an L1 layer, L2 layer, an IP layer, a UDPlayer, and a GTP-U layer to maintain communications with a PGW/SGW usingan address assigned by the PGW/SGW. PGW/SGW protocol stack 812 has an L1layer, L2, layer, IP layer related to an address assigned to the DeNB,UDP layer, GTP-U layer, and another IP layer related to an addressassigned to the UE.

According to an example, a UE can communicate with an ReNB to receiveaccess to a PGW/SGW. In this regard, UE can communicate over L1, MAC,RLC, and PDCP layers with the ReNB over using a EUTRA-Uu interface, asshown between protocol stacks 802 and 804. The UE can tunnel IP layercommunications through the ReNB and other entities to the PGW/SGW, whichassigns an IP address to the UE, as shown between protocol stacks 802and 812. To facilitate such tunneling, the ReNB communicates with a DeNBover L1, PDCP/RLC/MAC, and C-GTP-U/UDP/IP layers using an S1-U-Rinterface, as shown between protocol stacks 806 and 808. As described,the S1-U-R interface can be a newly defined interface that utilizes adisparate transport layer than communications between DeNB and PGW/SGW.In this regard, communications between ReNB and DeNB additionally use acompressed version of the GTP-U, UDP/IP headers. Moreover, thiscompressed header can indicate TEID, as described herein, of the ReNB inthe GTP-U header to facilitate return communications, as described,herein. DeNB can decouple the C-GTP-U/UDP/IP header from the transportlayer and communicate with the PGW over separate GTP-U, UDP, and IPlayers on top of L1 and L2 physical layers over an S1-U interface, asshown between protocol stacks 810 and 812. The same can be true fordownlink communications, as described, where DeNB decouples the GTP,UDP, and IP layers from the transport layers, compresses them into aC-GTP-U/UDP/IP header, and transmits over the PDCP/RLC/MAC and L1 layersto the ReNB. DeNB, as described, can use a TEID in the GTP-U header toroute the packet to the ReNB. In one example, this mitigates the needfor UDP/IP routing on the backhaul, etc.

Referring to FIG. 9, example protocol stacks 900 are illustrated thatfacilitate communicating in a wireless network to provide cell relayfunctionality for data (e.g., user) plane communications using a relayprotocol. A UE protocol stack 902 is shown comprising an L1 layer, MAClayer, an RLC layer, a PDCP layer, and an IP layer. A relay eNB 1 (ReNB)access link protocol stack 904 is depicted having an L1 layer, MAClayer, RLC layer, and PDCP layer, as well as an ReNB1 backhaul linkprotocol stack 906 having an L1 layer, MAC layer, RLC layer, PDCP layer,relay protocol (RP) layer, and a C-GTP-U/UDP/IP layer, which can be acompressed layer in one example, to facilitate communicating packets onthe backhaul. An intermediary ReNB2 access link protocol stack 908 isshown having an L1 layer, MAC layer, RLC layer, PDCP layer, and RPlayer, as well as a backhaul link protocol stack 910 for theintermediary ReNB2 having the same layers.

A DeNB access link protocol stack 908 is also shown having an L1 layer,MAC layer, RLC layer, PDCP layer, RP layer, and a C-GTP/UDP/IP layer, aswell as a DeNB backhaul link protocol stack 910 having an L1 layer, L2layer, a UDP/IP layer, and a GTP-U layer to maintain communications witha PGW/SGW using an address assigned by the PGW/SGW. PGW/SGW protocolstack 912 has an L1 layer, L2, layer, UDP/IP layer related to an addressassigned to the DeNB, GTP-U layer, and another IP layer related to anaddress assigned to the UE.

According to an example, a UE can communicate with an ReNB1 to receiveaccess to a PGW/SGW. In this regard, UE can communicate over L1, MAC,RLC, and PDCP layers with the ReNB1 over using a EUTRA-Uu interface, asshown between protocol stacks 902 and 904. The UE can tunnel IP layercommunications through the ReNB1 and other entities to the PGW/SGW,which assigns an IP address to the UE, as shown between protocol stacks902 and 916. To facilitate such tunneling, ReNB 1 communicates withReNB2 over an RP, as described herein, on top of L1, MAC, RLC, PDCPlayers using an S1-U-R interface (or other new interface forcommunicating using a relay protocol), as shown between protocol stacks906 and 908. In addition, the RP can carry the upper layerC-GTP-U/UDP/IP layer in the RP payload, as described previously, to thedisparate RP, as shown between protocol stacks 906 and 908. Moreover, asdescribed, the RP header can include an identifier of ReNB1, an IPaddress of the PGW/SGW, a protocol type indicating C-GTP-U/UDP/IP datain the RP payload, and/or the like.

ReNB2, and any other intermediary ReNBs, can forward the RPcommunication to the DeNB, as shown between protocol stack s 910 and912. In this example, DeNB can receive the RP packet, over the lowerlayers, and can extract the C-GTP-U/UDP/IP packet from the payload andcommunicate with the PGW over separate GTP-U, UDP, and IP layers on topof L1 and L2 physical layers over an S1-U interface, as shown betweenprotocol stacks 914 and 916. In one example, the DeNB can include therelay identifier from the RP packet header in the GTP-U communications.Thus, as described, downlink communications from PGW/SGW protocol stack912 can include the relay identifier. In this regard, upon receivingdownlink communications from PGW/SGW protocol stack 916 over DeNBbackhaul link protocol stack 914, DeNB access link protocol stack 912can generate an RP packet with a header comprising the relay identifierreceived over PGW/SGW protocol stack 916 and a compressed GTP-U/UDP/IPpacket as the payload. DeNB access link protocol stack 912 can transmitthe RP packet over ReNB2 backhaul link protocol stack 912, which canforward the RP packet over ReNB2 access link protocol stack 908 to ReNBbackhaul link protocol stack 906 based on the relay identifier in the RPheader, as described. ReNB1 backhaul link protocol stack 906 can obtainthe C-GTP-U/UDP/IP payload of the RP packet and forward to UE protocolstack 902, where the RP packet payload is of certain types, asdescribed.

Referring to FIGS. 10-14, methodologies relating to compressing and/orencapsulating packets for transmission in a wireless network using cellrelays are illustrated. While, for purposes of simplicity ofexplanation, the methodologies are shown and described as a series ofacts, it is to be understood and appreciated that the methodologies arenot limited by the order of acts, as some acts may, in accordance withone or more aspects, occur in different orders and/or concurrently withother acts from that shown and described herein. For example, thoseskilled in the art will understand and appreciate that a methodologycould alternatively be represented as a series of interrelated states orevents, such as in a state diagram. Moreover, not all illustrated actsmay be required to implement a methodology in accordance with one ormore aspects.

Turning to FIG. 10, an example methodology 1000 that facilitatesdecompressing a received header based at least in part on a RoHC contextis illustrated. At 1002, a packet with a RoHC compressed header can bereceived from at least one of a plurality of EPS bearers mapped to aDRB. As described, the packet can be RoHC compressed according to a RoHCcontext. At 1004, the RoHC context for the RoHC compressed header can bedetermined. For example, the RoHC context can be determined based on anidentifier in the RoHC header that relates to a RoHC compressioncontext, an identifier at least partially related to a respective UEbearer, such as a TEID and/or relay identifier in a tunneling protocolheader, and/or the like, as described. At 1006, the RoHC compressedheader can be decompressed based at least in part on the RoHC context.For example, the decompression, as described, can be performed by asingle decompressor that decompresses substantially all RoHC compressedheaders received from an upstream node, a decompressor specific to theEPS bearer, and/or the like. Moreover, the RoHC contexts can relate toprocedures utilized to compress the header that are known at thecompression and decompression nodes, as described; the RoHC contexts candiffer based on an EPS bearer type, data transmitted over the bearer,node type, available resources, and/or the like.

Referring to FIG. 11, an example methodology 1100 is shown thatfacilitates RoHC compressing packet headers using a RoHC context. At1102, a header of a packet received over an EPS bearer can be compressedbased at least in part on a RoHC context. As described, the RoHC contextcan be selected based at least in part on a bearer type, data type, nodetype, etc. At 1104, an identifier related to the RoHC context can beindicated in the packet. In this regard, a decompressor can determinethe RoHC context to utilize for decompressing the compressed header. At1106, the packet can be transmitted over a DRB to which the EPS bearerand one or more disparate EPS bearers are mapped.

Turning to FIG. 12, an example methodology 1200 that facilitatesencapsulating a packet or header in a tunneling protocol is illustrated.At 1202, an IP packet can be received from a core network fortransmitting to a UE bearer. For example, the IP packet can include aGTP header that specifies an identifier related at least in part to theUE bearer. At 1204, the IP header and/or packet can be encapsulated in atunneling protocol header that includes an identifier related to the UEbearer. As described, where the IP header is RoHC compressed, theidentifier can be utilized to determine a RoHC context for decompressingthe header. For example, the tunneling protocol header can be acompressed or uncompressed GTP-U header, an RP header, etc., and theidentifier can be a TEID, relay identifier, or portion thereof, etc. At1206, a tunneling protocol header type can be indicated in a PDCPportion of the packet. In this regard, a receiving node can determinethe encapsulated packet type to retrieve the IP packet and header. At1208, the packet can be transmitted to one or more relay nodes in acommunications path to the UE. As described, the one or more relay nodescan be determined from the identifier in the tunneling protocol header(e.g., as indicated in a routing table, in one example).

Referring to FIG. 13, an example methodology 1300 that facilitatesobtaining an IP packet and header from an encapsulated packet isillustrated. At 1302, a packet encapsulated in a tunneling protocolheader can be received. At 1304, a type of the tunneling protocol headercan be determined from an indicator in the PDCP portion of the packet.For example, the indicator can specify a compressed GTP-U, RP, IP, orsimilar type. Based on the type, at 1306, an IP packet and header can beretrieved from the packet. For example, if the packet or header is RoHCcompressed, and the indicator specifies compressed GTP-U, the GTP-Uheader can be decompressed and the IP packet and header retrieved fromthe payload. If the type is RP, the IP packet and header can beretrieved as the payload of the RP packet, for example.

Referring to FIG. 14, an example methodology 1400 that facilitatescompressing a UDP, IP, and/or GTP header of a packet is illustrated. At1402, a packet can be received from an upstream node comprising a UDP,IP, or GTP header. At 1404, the header of the packet can be compressedto include a compressed SGW IP address. As described, for example, anSGW IP address in a header received from a core network can becompressed to a one byte or other smaller sized value previouslycommunicated to a downstream node (e.g., in a transport addresstranslation response). In this regard, the compressed header can requireless bandwidth for transmission. It is to be appreciated that the headercan include additional fields and/or the additional fields can becompressed as well. At 1406, the packet with the compressed header canbe transmitted to a downstream node.

It will be appreciated that, in accordance with one or more aspectsdescribed herein, inferences can be made regarding determining a RoHCcontext and/or related identifier, associating a RoHC context with aTEID or relay identifier, and/or other aspects described herein. As usedherein, the term to “infer” or “inference” refers generally to theprocess of reasoning about or inferring states of the system,environment, and/or user from a set of observations as captured viaevents and/or data. Inference can be employed to identify a specificcontext or action, or can generate a probability distribution overstates, for example. The inference can be probabilistic—that is, thecomputation of a probability distribution over states of interest basedon a consideration of data and events. Inference can also refer totechniques employed for composing higher-level events from a set ofevents and/or data. Such inference results in the construction of newevents or actions from a set of observed events and/or stored eventdata, whether or not the events are correlated in close temporalproximity, and whether the events and data come from one or severalevent and data sources.

Referring now to FIG. 15, a wireless communication system 1500 isillustrated in accordance with various embodiments presented herein.System 1500 comprises a base station 1502 that can include multipleantenna groups. For example, one antenna group can include antennas 1504and 1506, another group can comprise antennas 1508 and 1510, and anadditional group can include antennas 1512 and 1514. Two antennas areillustrated for each antenna group; however, more or fewer antennas canbe utilized for each group. Base station 1502 can additionally include atransmitter chain and a receiver chain, each of which can in turncomprise a plurality of components associated with signal transmissionand reception (e.g., processors, modulators, multiplexers, demodulators,demultiplexers, antennas, etc.), as will be appreciated by one skilledin the art.

Base station 1502 can communicate with one or more mobile devices suchas mobile device 1516 and mobile device 1522; however, it is to beappreciated that base station 1502 can communicate with substantiallyany number of mobile devices similar to mobile devices 1516 and 1522.Mobile devices 1516 and 1522 can be, for example, cellular phones, smartphones, laptops, handheld communication devices, handheld computingdevices, satellite radios, global positioning systems, PDAs, and/or anyother suitable device for communicating over wireless communicationsystem 1500. As depicted, mobile device 1516 is in communication withantennas 1512 and 1514, where antennas 1512 and 1514 transmitinformation to mobile device 1516 over a forward link 1518 and receiveinformation from mobile device 1516 over a reverse link 1520. Moreover,mobile device 1522 is in communication with antennas 1504 and 1506,where antennas 1504 and 1506 transmit information to mobile device 1522over a forward link 1524 and receive information from mobile device 1522over a reverse link 1526. In a frequency division duplex (FDD) system,forward link 1518 can utilize a different frequency band than that usedby reverse link 1520, and forward link 1524 can employ a differentfrequency band than that employed by reverse link 1526, for example.Further, in a time division duplex (TDD) system, forward link 1518 andreverse link 1520 can utilize a common frequency band and forward link1524 and reverse link 1526 can utilize a common frequency band.

Each group of antennas and/or the area in which they are designated tocommunicate can be referred to as a sector of base station 1502. Forexample, antenna groups can be designed to communicate to mobile devicesin a sector of the areas covered by base station 1502. In communicationover forward links 1518 and 1524, the transmitting antennas of basestation 1502 can utilize beamforming to improve signal-to-noise ratio offorward links 1518 and 1524 for mobile devices 1516 and 1522. Also,while base station 1502 utilizes beamforming to transmit to mobiledevices 1516 and 1522 scattered randomly through an associated coverage,mobile devices in neighboring cells can be subject to less interferenceas compared to a base station transmitting through a single antenna toall its mobile devices. Moreover, mobile devices 1516 and 1522 cancommunicate directly with one another using a peer-to-peer or ad hoctechnology (not shown).

According to an example, system 1500 can be a multiple-inputmultiple-output (MIMO) communication system. Further, system 1500 canutilize substantially any type of duplexing technique to dividecommunication channels (e.g., forward link, reverse link, . . . ) suchas FDD, FDM, TDD, TDM, CDM, and the like. In addition, communicationchannels can be orthogonalized to allow simultaneous communication withmultiple devices over the channels; in one example, OFDM can be utilizedin this regard. Thus, the channels can be divided into portions offrequency over a period of time. In addition, frames can be defined asthe portions of frequency over a collection of time periods; thus, forexample, a frame can comprise a number of OFDM symbols. The base station1502 can communicate to the mobile devices 1516 and 1522 over thechannels, which can be create for various types of data. For example,channels can be created for communicating various types of generalcommunication data, control data (e.g., quality information for otherchannels, acknowledgement indicators for data received over channels,interference information, reference signals, etc.), and/or the like.

FIG. 16 shows an example wireless communication system 1600. Thewireless communication system 1600 depicts one base station 1610 and onemobile device 1650 for sake of brevity. However, it is to be appreciatedthat system 1600 can include more than one base station and/or more thanone mobile device, wherein additional base stations and/or mobiledevices can be substantially similar or different from example basestation 1610 and mobile device 1650 described below. In addition, it isto be appreciated that base station 1610 and/or mobile device 1650 canemploy the systems (FIGS. 1-7 and 15), protocol stacks (FIG. 8-9) and/ormethods (FIGS. 10-14) described herein to facilitate wirelesscommunication therebetween.

At base station 1610, traffic data for a number of data streams isprovided from a data source 1612 to a transmit (TX) data processor 1614.According to an example, each data stream can be transmitted over arespective antenna. TX data processor 1614 formats, codes, andinterleaves the traffic data stream based on a particular coding schemeselected for that data stream to provide coded data.

The coded data for each data stream can be multiplexed with pilot datausing orthogonal frequency division multiplexing (OFDM) techniques.Additionally or alternatively, the pilot symbols can be frequencydivision multiplexed (FDM), time division multiplexed (TDM), or codedivision multiplexed (CDM). The pilot data is typically a known datapattern that is processed in a known manner and can be used at mobiledevice 1650 to estimate channel response. The multiplexed pilot andcoded data for each data stream can be modulated (e.g., symbol mapped)based on a particular modulation scheme (e.g., binary phase-shift keying(BPSK), quadrature phase-shift keying (QPSK), M-phase-shift keying(M-PSK), M-quadrature amplitude modulation (M-QAM), etc.) selected forthat data stream to provide modulation symbols. The data rate, coding,and modulation for each data stream can be determined by instructionsperformed or provided by processor 1630.

The modulation symbols for the data streams can be provided to a TX MIMOprocessor 1620, which can further process the modulation symbols (e.g.,for OFDM). TX MIMO processor 1620 then provides N_(T) modulation symbolstreams to N_(T) transmitters (TMTR) 1622 a through 1622 t. In variousaspects, TX MIMO processor 1620 applies beamforming weights to thesymbols of the data streams and to the antenna from which the symbol isbeing transmitted.

Each transmitter 1622 receives and processes a respective symbol streamto provide one or more analog signals, and further conditions (e.g.,amplifies, filters, and upconverts) the analog signals to provide amodulated signal suitable for transmission over the MIMO channel.Further, N_(T) modulated signals from transmitters 1622 a through 1622 tare transmitted from N_(T) antennas 1624 a through 1624 t, respectively.

At mobile device 1650, the transmitted modulated signals are received byN_(R) antennas 1652 a through 1652 r and the received signal from eachantenna 1652 is provided to a respective receiver (RCVR) 1654 a through1654 r. Each receiver 1654 conditions (e.g., filters, amplifies, anddownconverts) a respective signal, digitizes the conditioned signal toprovide samples, and further processes the samples to provide acorresponding “received” symbol stream.

An RX data processor 1660 can receive and process the N_(R) receivedsymbol streams from N_(R) receivers 1654 based on a particular receiverprocessing technique to provide N_(T) “detected” symbol streams. RX dataprocessor 1660 can demodulate, deinterleave, and decode each detectedsymbol stream to recover the traffic data for the data stream. Theprocessing by RX data processor 1660 is complementary to that performedby TX MIMO processor 1620 and TX data processor 1614 at base station1610.

A processor 1670 can periodically determine which precoding matrix toutilize as discussed above. Further, processor 1670 can formulate areverse link message comprising a matrix index portion and a rank valueportion.

The reverse link message can comprise various types of informationregarding the communication link and/or the received data stream. Thereverse link message can be processed by a TX data processor 1638, whichalso receives traffic data for a number of data streams from a datasource 1636, modulated by a modulator 1680, conditioned by transmitters1654 a through 1654 r, and transmitted back to base station 1610.

At base station 1610, the modulated signals from mobile device 1650 arereceived by antennas 1624, conditioned by receivers 1622, demodulated bya demodulator 1640, and processed by a RX data processor 1642 to extractthe reverse link message transmitted by mobile device 1650. Further,processor 1630 can process the extracted message to determine whichprecoding matrix to use for determining the beamforming weights.

Processors 1630 and 1670 can direct (e.g., control, coordinate, manage,etc.) operation at base station 1610 and mobile device 1650,respectively. Respective processors 1630 and 1670 can be associated withmemory 1632 and 1672 that store program codes and data. Processors 1630and 1670 can also perform computations to derive frequency and impulseresponse estimates for the uplink and downlink, respectively.

It is to be understood that the aspects described herein can beimplemented in hardware, software, firmware, middleware, microcode, orany combination thereof. For a hardware implementation, the processingunits can be implemented within one or more application specificintegrated circuits (ASICs), digital signal processors (DSPs), digitalsignal processing devices (DSPDs), programmable logic devices (PLDs),field programmable gate arrays (FPGAs), processors, controllers,micro-controllers, microprocessors, other electronic units designed toperform the functions described herein, or a combination thereof.

When the aspects are implemented in software, firmware, middleware ormicrocode, program code or code segments, they can be stored in amachine-readable medium, such as a storage component. A code segment canrepresent a procedure, a function, a subprogram, a program, a routine, asubroutine, a module, a software package, a class, or any combination ofinstructions, data structures, or program statements. A code segment canbe coupled to another code segment or a hardware circuit by passingand/or receiving information, data, arguments, parameters, or memorycontents. Information, arguments, parameters, data, etc. can be passed,forwarded, or transmitted using any suitable means including memorysharing, message passing, token passing, network transmission, etc.

For a software implementation, the techniques described herein can beimplemented with modules (e.g., procedures, functions, and so on) thatperform the functions described herein. The software codes can be storedin memory units and executed by processors. The memory unit can beimplemented within the processor or external to the processor, in whichcase it can be communicatively coupled to the processor via variousmeans as is known in the art.

With reference to FIG. 17, illustrated is a system 1700 that facilitatesdecompressing RoHC headers in one or more received packets. For example,system 1700 can reside at least partially within a base station, mobiledevice, etc. It is to be appreciated that system 1700 is represented asincluding functional blocks, which can be functional blocks thatrepresent functions implemented by a processor, software, or combinationthereof (e.g., firmware). System 1700 includes a logical grouping 1702of electrical components that can act in conjunction. For instance,logical grouping 1702 can include an electrical component for receivinga packet with a RoHC compressed header from at least one of a pluralityof EPS bearers mapped to a DRB 1704. As described, system 1700 cansupport a number of UEs and thus can map the EPS bearers provided by acore network to single bearers. Additionally, logical grouping 1702 caninclude an electrical component for determining a RoHC context for theRoHC compressed header 1706. As described, this can include analyzing anidentifier in the RoHC header that indicates a RoHC context used forcompression, determining an identifier related at least in part to adownstream UE bearer that indicates the RoHC context, and/or the like.

Moreover, logical grouping 1702 can include an electrical component fordecompressing the RoHC compressed header based at least in part on theRoHC context 1708. In addition, for example, logical grouping 1702 caninclude an electrical component for extracting an identifier relating toa UE bearer the corresponds to the EPS bearer from a tunneling protocolheader that encapsulates the packet 1710. For example, the tunnelingprotocol can be a GTP-U, RP, and/or similar protocol, and theidentifier, as described can be a TEID, relay identifier, or portionthereof. The identifier can relate to the RoHC context, as describedpreviously. Additionally, system 1700 can include a memory 1712 thatretains instructions for executing functions associated with electricalcomponents 1704, 1706, 1708, and 1710. While shown as being external tomemory 1712, it is to be understood that one or more of electricalcomponents 1704, 1706, 1708, and 1710 can exist within memory 1712.

With reference to FIG. 18, illustrated is a system 1800 that facilitatesRoHC compressing packet headers for efficient transmission of relatedpackets in a wireless network that utilizes cell relays. For example,system 1800 can reside at least partially within a base station, mobiledevice, etc. It is to be appreciated that system 1800 is represented asincluding functional blocks, which can be functional blocks thatrepresent functions implemented by a processor, software, or combinationthereof (e.g., firmware). System 1800 includes a logical grouping 1802of electrical components that can act in conjunction. For instance,logical grouping 1802 can include an electrical component forcompressing a header of a packet received over an EPS bearer based atleast in part on a RoHC context 1804. For example, as described, theRoHC context can vary depending on one or more factors relating tosystem 1800, core network, and/or the like, such as EPS bearer type,data type transmitted over the EPS bearer, node type, availableresources, etc. Additionally, logical grouping 1802 can include anelectrical component for indicating an identifier related to the RoHCcontext in the packet 1806. As described, this can include a RoHCcontext identifier in a RoHC header, an identifier related at least inpart to a UE bearer indicated in a tunneling protocol header (e.g., aTEID or relay identifier in a GTP-U or RP header), and/or the like.

Moreover, logical grouping 1802 can include an electrical component fortransmitting the packet header over a DRB to which the EPS bearer andone or more additional EPS bearers are mapped 1808. In addition, logicalgrouping 1802 can include an electrical component for selecting the RoHCcontext 1810. This can be based on one or more of the describedparameters, in one example, provisioned from a core network, and/or thelike. Further, logical grouping 1802 can include an electrical componentfor encapsulating the header or the packet in a tunneling protocolheader 1812. As described, this can be a GTP-U header, an RP header,and/or the like, to facilitate packet routing among various cell relays.Additionally, system 1800 can include a memory 1814 that retainsinstructions for executing functions associated with electricalcomponents 1804, 1806, 1808, 1810, and 1812. While shown as beingexternal to memory 1814, it is to be understood that one or more ofelectrical components 1804, 1806, 1808, 1810, and 1812 can exist withinmemory 1814.

With reference to FIG. 19, illustrated is a system 1900 that facilitatescompressing UDP, IP, or GTP headers in received packets for forwardingto downstream nodes. For example, system 1900 can reside at leastpartially within a base station, mobile device, etc. It is to beappreciated that system 1900 is represented as including functionalblocks, which can be functional blocks that represent functionsimplemented by a processor, software, or combination thereof (e.g.,firmware). System 1900 includes a logical grouping 1902 of electricalcomponents that can act in conjunction. For instance, logical grouping1902 can include an electrical component for receiving a packet from anupstream node comprising a UDP, IP, or GTP header 1904. Additionally,logical grouping 1902 can include an electrical component for applyingcompression to a header of the packet to compress at least an SGW IPaddress 1906.

As described, compressing the SGW IP address can include utilizing acompressed version of the SGW IP address negotiated during a transportaddress translation request/response procedure with system 1900.Moreover, logical grouping 1902 can include an electrical component fortransmitting the packet with the compressed header to a downstream node1908. Utilizing the compressed header, as described, can conservebandwidth for more efficient transmitting. Additionally, system 1900 caninclude a memory 1910 that retains instructions for executing functionsassociated with electrical components 1904, 1906, and 1908. While shownas being external to memory 1910, it is to be understood that one ormore of electrical components 1904, 1906, and 1908 can exist withinmemory 1910.

The various illustrative logics, logical blocks, modules, and circuitsdescribed in connection with the embodiments disclosed herein may beimplemented or performed with a general purpose processor, a digitalsignal processor (DSP), an application specific integrated circuit(ASIC), a field programmable gate array (FPGA) or other programmablelogic device, discrete gate or transistor logic, discrete hardwarecomponents, or any combination thereof designed to perform the functionsdescribed herein. A general-purpose processor may be a microprocessor,but, in the alternative, the processor may be any conventionalprocessor, controller, microcontroller, or state machine. A processormay also be implemented as a combination of computing devices, e.g., acombination of a DSP and a microprocessor, a plurality ofmicroprocessors, one or more microprocessors in conjunction with a DSPcore, or any other such configuration. Additionally, at least oneprocessor may comprise one or more modules operable to perform one ormore of the steps and/or actions described above.

Further, the steps and/or actions of a method or algorithm described inconnection with the aspects disclosed herein may be embodied directly inhardware, in a software module executed by a processor, or in acombination of the two. A software module may reside in RAM memory,flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a harddisk, a removable disk, a CD-ROM, or any other form of storage mediumknown in the art. An exemplary storage medium may be coupled to theprocessor, such that the processor can read information from, and writeinformation to, the storage medium. In the alternative, the storagemedium may be integral to the processor. Further, in some aspects, theprocessor and the storage medium may reside in an ASIC. Additionally,the ASIC may reside in a user terminal. In the alternative, theprocessor and the storage medium may reside as discrete components in auser terminal. Additionally, in some aspects, the steps and/or actionsof a method or algorithm may reside as one or any combination or set ofcodes and/or instructions on a machine readable medium and/or computerreadable medium, which may be incorporated into a computer programproduct.

In one or more aspects, the functions described may be implemented inhardware, software, firmware, or any combination thereof. If implementedin software, the functions may be stored or transmitted as one or moreinstructions or code on a computer-readable medium. Computer-readablemedia includes both computer storage media and communication mediaincluding any medium that facilitates transfer of a computer programfrom one place to another. A storage medium may be any available mediathat can be accessed by a computer. By way of example, and notlimitation, such computer-readable media can comprise RAM, ROM, EEPROM,CD-ROM or other optical disk storage, magnetic disk storage or othermagnetic storage devices, or any other medium that can be used to carryor store desired program code in the form of instructions or datastructures and that can be accessed by a computer. Also, any connectionmay be termed a computer-readable medium. For example, if software istransmitted from a website, server, or other remote source using acoaxial cable, fiber optic cable, twisted pair, digital subscriber line(DSL), or wireless technologies such as infrared, radio, and microwave,then the coaxial cable, fiber optic cable, twisted pair, DSL, orwireless technologies such as infrared, radio, and microwave areincluded in the definition of medium. Disk and disc, as used herein,includes compact disc (CD), laser disc, optical disc, digital versatiledisc (DVD), floppy disk and blu-ray disc where disks usually reproducedata magnetically, while discs usually reproduce data optically withlasers. Combinations of the above should also be included within thescope of computer-readable media.

While the foregoing disclosure discusses illustrative aspects and/orembodiments, it should be noted that various changes and modificationscould be made herein without departing from the scope of the describedaspects and/or embodiments as defined by the appended claims.Furthermore, although elements of the described aspects and/orembodiments may be described or claimed in the singular, the plural iscontemplated unless limitation to the singular is explicitly stated.Additionally, all or a portion of any aspect and/or embodiment may beutilized with all or a portion of any other aspect and/or embodiment,unless stated otherwise. Furthermore, to the extent that the term“includes” is used in either the detailed description or the claims,such term is intended to be inclusive in a manner similar to the term“comprising” as “comprising” is interpreted when employed as atransitional word in a claim. Furthermore, although elements of thedescribed aspects and/or aspects may be described or claimed in thesingular, the plural is contemplated unless limitation to the singularis explicitly stated. Additionally, all or a portion of any aspectand/or embodiment may be utilized with all or a portion of any otheraspect and/or embodiment, unless stated otherwise.

1. A method, comprising: receiving a packet with a robust headercompression (RoHC) compressed header from at least one of a plurality ofevolved packet system (EPS) bearers mapped to a dedicated radio bearer(DRB); determining a RoHC context for the RoHC compressed header; anddecompressing the RoHC compressed header based at least in part on theRoHC context.
 2. The method of claim 1, wherein the determining the RoHCcontext includes obtaining a RoHC context identifier from a RoHC headerof the packet.
 3. The method of claim 1, further comprising obtaining anidentifier for routing the packet from a tunneling protocol header,wherein the packet or the RoHC compressed header is encapsulated in thetunneling protocol header.
 4. The method of claim 3, wherein thedetermining the RoHC context includes determining the RoHC context basedat least in part on the identifier.
 5. The method of claim 4, whereinthe tunneling protocol header is a general packet radio service (GPRS)tunneling protocol (GTP)-U header and the identifier is a tunnelendpoint identifier (TEID).
 6. The method of claim 4, wherein thetunneling protocol header is a relay protocol header and the identifieris a relay identifier assigned by a donor evolved Node B (eNB).
 7. Themethod of claim 1, further comprising providing an internet protocol(IP) header and a related IP packet to a downstream user equipment (UE),wherein decompressing the RoHC compressed header yields the IP header.8. A wireless communications apparatus, comprising: at least oneprocessor configured to: obtain a packet with a robust headercompression (RoHC) compressed header from one of a plurality of evolvedpacket system (EPS) bearers mapped to a dedicated radio bearer (DRB) ofthe wireless communications apparatus; discern a RoHC context used forcompression of the RoHC compressed header; and decompress the RoHCcompressed header according to the RoHC context; and a memory coupled tothe at least one processor.
 9. The wireless communications apparatus ofclaim 8, wherein the at least one processor discerns the RoHC contextbased at least in part on a RoHC context identifier in a header of thepacket with the RoHC compressed header.
 10. The wireless communicationsapparatus of claim 8, wherein the at least one processor is furtherconfigured to extract an identifier having at least a portion relatingto a corresponding user equipment (UE) bearer from a tunneling protocolheader within which the packet or the RoHC compressed header isencapsulated.
 11. The wireless communications apparatus of claim 10,wherein the at least one processor discerns the RoHC context based atleast in part on the identifier.
 12. The wireless communicationsapparatus of claim 11, wherein the tunneling protocol header is ageneral packet radio service (GPRS) tunneling protocol (GTP)-U headerand the identifier is a tunnel endpoint identifier (TEID).
 13. Thewireless communications apparatus of claim 11, wherein the tunnelingprotocol header is a relay protocol header and the identifier is a relayidentifier assigned by a donor evolved Node B (eNB).
 14. An apparatus,comprising: means for receiving a packet with a robust headercompression (RoHC) compressed header from at least one of a plurality ofevolved packet system (EPS) bearers mapped to a dedicated radio bearer(DRB); means for determining a RoHC context for the RoHC compressedheader; and means for decompressing the RoHC compressed header based atleast in part on the RoHC context.
 15. The apparatus of claim 14,wherein the means for determining the RoHC context determines the RoHCcontext based at least in part on a RoHC context identifier in a RoHCheader of the packet.
 16. The apparatus of claim 14, further comprisingmeans for extracting an identifier relating to a user equipment (UE)bearer that corresponds to the at least one of the plurality of EPSbearers from a tunneling protocol header that encapsulates the packet.17. The apparatus of claim 16, wherein the means for determining theRoHC context determines the RoHC context based at least in part on theidentifier.
 18. The apparatus of claim 17, wherein the tunnelingprotocol header is a general packet radio service (GPRS) tunnelingprotocol (GTP)-U header and the identifier is a tunnel endpointidentifier (TEID).
 19. The apparatus of claim 17, wherein the tunnelingprotocol header is a relay protocol header and the identifier is a relayidentifier.
 20. A computer program product, comprising: acomputer-readable medium comprising: code for causing at least onecomputer to receive a packet with a robust header compression (RoHC)compressed header from at least one of a plurality of evolved packetsystem (EPS) bearers mapped to a dedicated radio bearer (DRB); code forcausing the at least one computer to determine a RoHC context for theRoHC compressed header; and code for causing the at least one computerto decompress the RoHC compressed header based at least in part on theRoHC context.
 21. The computer program product of claim 20, wherein thecode for causing the at least one computer to determine the RoHC contextobtains a RoHC context identifier from a RoHC header of the packet. 22.The computer program product of claim 20, wherein the computer-readablemedium further comprises code for causing the at least one computer toobtain a local identifier from a tunneling protocol header, wherein thepacket is encapsulated in the tunneling protocol header.
 23. Thecomputer program product of claim 22, wherein the code for causing theat least one computer to determine the RoHC context determines the RoHCcontext based at least in part on the local identifier.
 24. The computerprogram product of claim 23, wherein the tunneling protocol header is ageneral packet radio service (GPRS) tunneling protocol (GTP)-U headerand the local identifier is a tunnel endpoint identifier (TEID).
 25. Thecomputer program product of claim 23, wherein the tunneling protocolheader is a relay protocol header and the local identifier is a relayidentifier assigned by a donor evolved Node B (eNB).
 26. An apparatus,comprising: a bearer communicating component that receives a packet witha robust header compression (RoHC) compressed header from at least oneof a plurality of evolved packet system (EPS) bearers mapped to adedicated radio bearer (DRB); a RoHC context determining component thatdiscerns a RoHC context for the RoHC compressed header; and a RoHCdecompressing component that decompresses the RoHC compressed headerbased at least in part on the RoHC context.
 27. The apparatus of claim26, wherein the RoHC context determining component discerns the RoHCcontext based at least in part on a RoHC context identifier in a RoHCheader of the packet.
 28. The apparatus of claim 26, further comprisingan identifier receiving component that extracts an identifier relatingto a user equipment (UE) bearer that corresponds to the at least one ofthe plurality of EPS bearers from a tunneling protocol header thatencapsulates the packet.
 29. The apparatus of claim 28, wherein the RoHCcontext determining component discerns the RoHC context based at leastin part on the identifier.
 30. The apparatus of claim 29, wherein thetunneling protocol header is a general packet radio service (GPRS)tunneling protocol (GTP)-U header and the identifier is a tunnelendpoint identifier (TEID).
 31. The apparatus of claim 29, wherein thetunneling protocol header is a relay protocol header and the identifieris a relay identifier.
 32. A method, comprising: compressing a header ofa packet received over an evolved packet system (EPS) bearer usingrobust header compression (RoHC) based at least in part on a RoHCcontext; indicating an identifier related to the RoHC context in thepacket; and transmitting the packet over a dedicated radio bearer (DRB)to which the EPS bearer and one or more additional EPS bearers aremapped.
 33. The method of claim 32, further comprising selecting a RoHCcontext identifier for the packet, wherein the compressing the headerusing RoHC is based at least in part on the RoHC context identifier. 34.The method of claim 33, wherein the indicating the identifier includesspecifying the RoHC context identifier in a RoHC header of the packet.35. The method of claim 32, further comprising encapsulating the headeror the packet in a tunneling protocol header, wherein the indicating theidentifier includes specifying the identifier in the tunneling protocolheader.
 36. The method of claim 35, wherein the tunneling protocolheader is a general packet radio service (GPRS) tunneling protocol(GTP)-U header, and the identifier is a tunnel endpoint identifier(TEID).
 37. The method of claim 35, wherein the tunneling protocolheader is a relay protocol header, and the identifier is a relayidentifier assigned by a donor evolved Node B (eNB).
 38. The method ofclaim 32, wherein the packet is an IP packet received from a corenetwork for communicating to a user equipment (UE).
 39. A wirelesscommunications apparatus, comprising: at least one processor configuredto: compress a header of a packet received over an evolved packet system(EPS) bearer based at least in part on a selected robust headercompression (RoHC) context; specify an identifier related to theselected RoHC context in the packet; and communicate the packet over adedicated radio bearer (DRB) to which the EPS bearer and one or moredisparate EPS bearers in a core network are mapped; and a memory coupledto the at least one processor.
 40. The wireless communications apparatusof claim 39, wherein the at least one processor is further configured toselect a RoHC context identifier for the packet and the selected RoHCcontext relates to the RoHC context identifier.
 41. The wirelesscommunications apparatus of claim 40, wherein the identifier is a RoHCcontext identifier in a RoHC header of the packet.
 42. The wirelesscommunications apparatus of claim 39, wherein the at least one processoris further configured to encapsulate the header or the packet in atunneling protocol header, and the identifier is related to a relayevolved Node B (eNB) that provides the DRB specified in the tunnelingprotocol header.
 43. The wireless communications apparatus of claim 42,wherein the tunneling protocol header is a general packet radio service(GPRS) tunneling protocol (GTP)-U header, and the identifier is a tunnelendpoint identifier (TEID).
 44. The wireless communications apparatus ofclaim 42, wherein the tunneling protocol header is a relay protocolheader, and the identifier is a relay identifier.
 45. An apparatus,comprising: means for compressing a header of a packet received over anevolved packet system (EPS) bearer based at least in part on a robustheader compression (RoHC) context; means for indicating an identifierrelated to the RoHC context in the packet; and means for transmittingthe header over a dedicated radio bearer (DRB) to which the EPS bearerand one or more additional EPS bearers are mapped.
 46. The apparatus ofclaim 45, further comprising means for selecting the RoHC context. 47.The apparatus of claim 46, wherein the means for indicating theidentifier specifies an identifier of the RoHC context in a RoHC headerof the packet.
 48. The apparatus of claim 45, further comprising meansfor encapsulating the header or the packet in a tunneling protocolheader, wherein the means for indicating the identifier specifies theidentifier in the tunneling protocol header.
 49. The apparatus of claim48, wherein the tunneling protocol header is a general packet radioservice (GPRS) tunneling protocol (GTP)-U header, and the identifier isa tunnel endpoint identifier (TEID).
 50. The apparatus of claim 48,wherein the tunneling protocol header is a relay protocol header, andthe identifier is a relay identifier.
 51. A computer program product,comprising: a computer-readable medium comprising: code for causing atleast one computer to compress a header of a packet received over anevolved packet system (EPS) bearer using robust header compression(RoHC) based at least in part on a RoHC context; code for causing the atleast one computer to indicate an identifier related to the RoHC contextin the packet; and code for causing the at least one computer totransmit the packet over a dedicated radio bearer (DRB) to which the EPSbearer and one or more additional EPS bearers are mapped.
 52. Thecomputer program product of claim 51, wherein the computer-readablemedium further comprises code for causing the at least one computer toselect a RoHC context identifier for the packet, wherein the code forcausing the at least one computer to compress the header using RoHCcompresses the header based at least in part on the RoHC contextidentifier.
 53. The computer program product of claim 52, wherein thecode for causing the at least one computer to indicate the identifierspecifies the RoHC context identifier in a RoHC header of the packet.54. The computer program product of claim 51, wherein thecomputer-readable medium further comprises code for causing the at leastone computer to encapsulate the header or the packet in a tunnelingprotocol header, wherein the code for causing the at least one computerto indicate the identifier specifies the identifier in the tunnelingprotocol header.
 55. The computer program product of claim 54, whereinthe tunneling protocol header is a general packet radio service (GPRS)tunneling protocol (GTP)-U header, and the identifier is a tunnelendpoint identifier (TEID).
 56. The computer program product of claim54, wherein the tunneling protocol header is a relay protocol header,and the identifier is a relay identifier assigned by a donor evolvedNode B (eNB).
 57. An apparatus, comprising: a robust header compression(RoHC) compressing component that compresses a header of a packetreceived over an evolved packet system (EPS) bearer using RoHC based atleast in part on a RoHC context; a context identifying component thatspecifies an identifier related to the RoHC context in the packet; and abearer communicating component that transmits the header over adedicated radio bearer (DRB) to which the EPS bearer and one or moreadditional EPS bearers are mapped.
 58. The apparatus of claim 57,further comprising a RoHC context selecting component that determinesthe RoHC context.
 59. The apparatus of claim 58, wherein the contextidentifying component is a RoHC context indicating component thatspecifies an identifier of the RoHC context in a RoHC header of thepacket.
 60. The apparatus of claim 57, further comprising a packetencapsulating component that inserts the header or the packet in atunneling protocol header, wherein the context identifying component isan identifier specifying component that indicates the identifier in thetunneling protocol header.
 61. The apparatus of claim 60, wherein thetunneling protocol header is a general packet radio service (GPRS)tunneling protocol (GTP)-U header, and the identifier is a tunnelendpoint identifier (TEID).
 62. The apparatus of claim 60, wherein thetunneling protocol header is a relay protocol header, and the identifieris a relay identifier.
 63. A method, comprising: receiving a packet froman upstream node comprising a user datagram protocol (UDP), internetprotocol (IP), or general packet radio service (GPRS) tunneling protocol(GTP) header; compressing the header of the packet to include acompressed serving gateway (SGW) IP address; and transmitting the packetwith the compressed header to a downstream node.
 64. The method of claim63, wherein the compressed SGW IP address is of a smaller size than anSGW IP address specified in the header before compression.
 65. Themethod of claim 63, further comprising generating the compressed SGW IPaddress based at least in part on a transport address translationrequest received from the downstream node.
 66. The method of claim 63,wherein the compressing the header further comprises compressing theheader to include a message type, a tunnel endpoint identifier (TEID), asequence number, a N-packet data unit (PDU) number, or a next extensionheader type.
 67. A wireless communications apparatus, comprising: atleast one processor configured to: obtain a packet from an upstream nodecomprising a user datagram protocol (UDP), internet protocol (IP), orgeneral packet radio service (GPRS) tunneling protocol (GTP) header;associate a compressed header with the packet that includes a compressedserving gateway (SGW) IP address; and transmit the packet with thecompressed header to a downstream node; and a memory coupled to the atleast one processor.
 68. The wireless communications apparatus of claim67, wherein the compressed SGW IP address is of a smaller size than anSGW IP address specified in the header of the packet.
 69. The wirelesscommunications apparatus of claim 67, wherein the at least one processoris further configured to generate the compressed SGW IP address based atleast in part on a transport address translation request received fromthe downstream node.
 70. The wireless communications apparatus of claim67, wherein the compressed header additionally includes a message type,a tunnel endpoint identifier (TEID), a sequence number, a N-packet dataunit (PDU) number, or a next extension header type.
 71. An apparatus,comprising: means for receiving a packet from an upstream nodecomprising a user datagram protocol (UDP), internet protocol (IP), orgeneral packet radio service (GPRS) tunneling protocol (GTP) header;means for applying compression to the header of the packet to compressat least an serving gateway (SGW) IP address; and means for transmittingthe packet with the compressed header to a downstream node.
 72. Theapparatus of claim 71, wherein the means for applying compression to theheader compresses the SGW IP address to a smaller byte size.
 73. Theapparatus of claim 71, wherein the means for applying compressiongenerates a compressed representation of the SGW IP address in responseto a transport address translation request received from the downstreamnode.
 74. The apparatus of claim 71, wherein the compressed headerfurther includes a message type, a tunnel endpoint identifier (TEID), asequence number, a N-packet data unit (PDU) number, or a next extensionheader type.
 75. A computer program product, comprising: acomputer-readable medium comprising: code for causing at least onecomputer to receive a packet from an upstream node comprising a userdatagram protocol (UDP), internet protocol (IP), or general packet radioservice (GPRS) tunneling protocol (GTP) header; code for causing the atleast one computer to compress the header of the packet to include acompressed serving gateway (SGW) IP address; and code for causing the atleast one computer to transmit the packet with the compressed header toa downstream node.
 76. The computer program product of claim 75, whereinthe compressed SGW IP address is of a smaller size than an SGW IPaddress specified in the header before compression.
 77. The computerprogram product of claim 75, wherein the computer-readable mediumfurther comprises code for causing the at least one computer to generatethe compressed SGW IP address based at least in part on a transportaddress translation request received from the downstream node.
 78. Thecomputer program product of claim 75, wherein the code for causing theat least one computer to compress the header further compresses theheader to include a message type, a tunnel endpoint identifier (TEID), asequence number, a N-packet data unit (PDU) number, or a next extensionheader type.
 79. An apparatus, comprising: an internet protocol (IP)packet receiving component that receives a packet from an upstream nodecomprising a user datagram protocol (UDP), IP, or general packet radioservice (GPRS) tunneling protocol (GTP) header; a header compressingcomponent compresses the header of the packet at least in part bycompressing an serving gateway (SGW) IP address in the header; and abearer communicating component that transmits the packet with thecompressed header to a downstream node.
 80. The apparatus of claim 79,wherein the header compressing component compresses the SGW IP addressto a smaller byte size.
 81. The apparatus of claim 79, wherein theheader compressing component generates a compressed representation ofthe SGW IP address in response to a transport address translationrequest received from the downstream node.
 82. The apparatus of claim79, wherein the compressed header further includes a message type, atunnel endpoint identifier (TEID), a sequence number, a N-packet dataunit (PDU) number, or a next extension header type.